which kanshi & sway version are u using?
I have

• https://github.com/emersion/kanshi master branch
• sway 1.7

profile {
    output "Toshiba America Info Systems Inc 43UHD_LCD_TV 0x00000000 (HDMI-A-2)" position 1920,0 mode 4096x2160@30.0000 scale 1.00 transform normal
    output "Chimei Innolux Corporation 0x1245 0x00000000 (eDP-1)" position 2980,2160 mode 1920x1080@60.0010 scale 1.00 transform normal
}
profile {
    output "Unknown HP 727pu CN44211RVS (DP-2)" position 0,0 mode 2560x1440@59.9510 scale 1.00 transform normal
    output "Chimei Innolux Corporation 0x1245 0x00000000 (eDP-1)" position 360,1440 mode 1920x1080@60.0010 scale 1.00 transform normal
}
profile {
    output "Unknown HP 727pu CN44211RVS (DP-1)" position 0,0 mode 2560x1440@59.9510 scale 1.00 transform normal
    output "Chimei Innolux Corporation 0x1245 0x00000000 (eDP-1)" position 640,1440 mode 1920x1080@60.0010 scale 1.00 transform normal
}
profile {
    output "Unknown D221SV-F 16NF006538Q0 (DP-1 via HDMI)" position 1920,0 mode 1920x1080@100.0000 scale 1.00 transform normal
    output "Chimei Innolux Corporation 0x1245 0x00000000 (eDP-1)" position 1920,1080 mode 1920x1080@60.0010 scale 1.00 transform normal
}

Parts of my config are like that, it work and quite stable for me. I have multiple ports and different monitors in office/home/university, you solution tried all different monitors pluged into DP-1 as the same one, which is not a good idea in my opinion.

@petertheprocess Thanks for the response! Your configuration works perfectly because you're using the legacy quoted format that the original matching logic supports.

The core issue: There's a mismatch between what wdisplays writes vs what it can read. Currently:

• wdisplays writes: output DP-3 position ... (unquoted port names)
• match() function reads: only "Long Description (DP-3)" (quoted descriptions)

This causes the matching to fail, creating duplicate profiles instead of updating existing ones.

What my PR does:

1. Write format: Changes from head->description to head->name (shorter, cleaner port names)
2. Read format: Supports both quoted descriptions AND unquoted port names
3. Backward compatibility: Your existing config will continue to work unchanged

Why this aligns with kanshi spec:
According to kanshi(5), valid output criteria include:

• Output names: "DP-1" ✅
• Manufacturer/model/serial: "Company Model Serial" ✅

The current implementation writes invalid hybrid format: "Company Model Serial (DP-3)" which doesn't match either specification.

Your concern about port ambiguity is valid, but using port names (DP-1, DP-3) is actually more stable than descriptions, since the same physical port will always have the same name regardless of which monitor is connected.

The change improves robustness while maintaining full backward compatibility with your existing setup. Would you like me to clarify any part of the implementation?

@zipproth Thanks for your explaination, now I understand the issue.

I did some search and find it is caused by that:
Starting with Kanshi 1.7, the match_profile_output function was updated to use fnmatch, which changes how output matching works compared to earlier versions (like 1.2.0 I had).

static bool match_profile_output(struct kanshi_profile_output *output,
		struct kanshi_head *head) {
	const char *make = head->make ? head->make : "Unknown";
	const char *model = head->model ? head->model : "Unknown";
	const char *serial_number =
		head->serial_number ? head->serial_number : "Unknown";

	char identifier[1024];
	assert(sizeof(identifier) >= strlen(make) + strlen(model) + strlen(serial_number) + 3);
	snprintf(identifier, sizeof(identifier), "%s %s %s", make, model, serial_number);

	return strcmp(output->name, "*") == 0 ||
		strcmp(output->name, head->name) == 0 ||
		fnmatch(output->name, identifier, 0) == 0;
}

I would like to create a PR for kanshi to make it compatible with legacy quoted format instead of only recording the port name, but you are right your solution is more stable. Anyway, I will look into it more in detail when I have time.

While investigating the consequences of choosing either port name or display serial, I ran into an other related issue:

Modern kanshi syntax can be more complex and the parser from store.c will crash if the syntax is a bit more complex than a list of output profiles, eg:

output "Dell Inc. DELL P2214H 29C295A4527S" mode 1920x1080 alias $dell_left
output "Dell Inc. DELL P2213 Y57VF617BLZS" mode 1680x1050 alias $dell_middle
output eDP-1 mode 1920x1080 alias $internal

profile otg {
    output $internal position 0,0
}

profile desk {
  output $dell_left position 0,0
  output $dell_middle position 1920,30
  output $internal position 1800,1080
}

I believe the long-term solution would be to use the same parser as kanshi : https://codeberg.org/emersion/libscfg

An other (complementary) solution would be to always create our kanshi config file separate from the main config file and use the include directive. This way, complex configurations can be stored in the main config file and simple configurations generated by wdisplays would not interfere.

With the current implementation, we can already have wdisplays write to a separate file just by setting an environment variable.

IMHO it would be better to save profiles from wdisplays using display names rather than output names to allow user-defined generic profiles based on output names without risking erasing them.

@petertheprocess and @JasonGantner I've updated this PR by merging the latest master into my branch 'fix-kanshi-output-names' to resolve some conflicts and keep it current. Additionally, I created a separate branch 'rebase-for-jason' rebased on @JasonGantner's 'v1.2.0-work' to address his merge request in JasonGantner#4 (see my comment there for details).

Regarding @JasonGantner's suggestions: I agree that using libscfg for a more robust parser would be a great long-term solution to handle complex kanshi syntax (e.g., aliases). Also, saving profiles in a separate file with 'include' is a good idea to avoid interference – the current env variable support already enables this partially. If there's interest, we could discuss integrating that next.

Let me know if this merge looks good or if further adjustments are needed!

Best,
Stefan